✅ Deploy Preview for cedarjs ready!

Name	Link
🔨 Latest commit	e1a0645
🔍 Latest deploy log	https://app.netlify.com/projects/cedarjs/deploys/69f29284d002750008a9a8c7
😎 Deploy Preview	https://deploy-preview-1663--cedarjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

Greptile Summary

Implements Phases 2–4 of Universal Deploy integration: buildCedarDispatcher / createCedarFetchable in @cedarjs/api-server, cedarUniversalDeployPlugin + buildUDApiServer in @cedarjs/vite, cedar serve api --ud CLI opt-in, and a fully-implemented (not yet wired) cedarDevDispatcherPlugin for the future single-port dev server. Issues from previous reviews (ESM cache-busting, race condition in the dev dispatcher, isApiRequest prefix matching, Windows path separators, apiAvailablePort regression in devHandler) are all addressed in this revision.

Confidence Score: 5/5

Safe to merge; only P2 findings remain.

All previous P1 findings are resolved. Two P2 findings remain: a doc misattribution of buildUDApiServer and an unconditional UD Vite build step that adds latency to all API builds. Neither blocks correctness.

docs/implementation-docs/2026-03-26-cedarjs-project-overview.md (api-server row) and packages/cli/src/commands/build/buildHandler.ts (unconditional UD build task)

Important Files Changed

_{Reviews (22): Last reviewed commit: "make phase 4 vs phase 5 more clear" | Re-trigger Greptile}

🤖 Nx Cloud AI Fix

Ensure the fix-ci command is configured to always run in your CI pipeline to get automatic fixes in future runs. For more information, please see https://nx.dev/ci/features/self-healing-ci

View your CI Pipeline Execution ↗ for commit e1a0645

☁️ Nx Cloud last updated this comment at 2026-04-29 23:37:33 UTC

@greptileai you said "This PR adds Phase 2 of the Universal Deploy integration". What's left to do for Phase 3, to also be able to include that in this PR?

According to the implementation plan, Phase 3's exit criteria are:

1. Cedar can run in production on Node without Fastify — the createUDServer (srvx-based) covers this for the standalone UD server, but the plan specifically calls for @universal-deploy/adapter-node to be the mechanism, not a custom srvx server.

2. Cedar's server entries registered in the UD store at build time — the Vite plugin does call addEntry(), but the virtual module it returns is a 501 stub:

   // vite-plugin-cedar-universal-deploy.ts
   return new Response(
     'Cedar API virtual entry: not yet implemented (Phase 5)',
     { status: 501 },
   )

   This needs to be replaced with a real Fetchable that dispatches to the discovered Cedar API functions.

3. yarn cedar serve no longer depends on Fastify — not addressed yet.

So concretely, what's left:

• Replace the 501 stub in vite-plugin-cedar-universal-deploy.ts's load() with a real Cedar API dispatcher. The route discovery logic already exists in createUDServer.ts — the pieces are there, they just need to be wired into the virtual module's fetch handler.
• Validate @universal-deploy/adapter-node end-to-end (the plan calls this out explicitly as a Phase 3 deliverable).
• Wire yarn cedar serve to delegate to the UD node adapter rather than Fastify.

The plan notes that Phase 3's real Fetchable implementation depends on the Phase 2 route manifest — which is partly why the PR punted it to Phase 5. But since Phase 2 route discovery is also in this PR (createUDServer handles it at runtime), you have enough to at least make the virtual module non-stub and do the end-to-end validation.

The changes in this PR are now available on npm.

Try them out by running yarn cedar upgrade -t 4.0.0-canary.13870

Or try it in a new app with yarn dlx create-cedar-app@4.0.0-canary.13870